Space awareness for Elastic Defend #1943
Conversation
|
🔍 Preview links for changed docs:
🔔 The preview site may take up to 3 minutes to finish building. These links will become live once it completes. |
solutions/security/configure-elastic-defend/elastic-defend-feature-privileges.md
Outdated
Show resolved
Hide resolved
Co-authored-by: florent-leborgne <[email protected]>
|
@benironside can we merge this? |
|
@bmorelli25 no, after my meeting with Caitlin there's something else I need to add. Working on it now. |
|
|
||
| # Spaces and {{elastic-sec}} FAQ [security-spaces-faq] | ||
|
|
||
| This page introduces {{elastic-sec}} space awareness and answers frequently asked questions about how {{elastic-defend}} integration policies, {{elastic-endpoint}} artifacts, and {{elastic-endpoint}} response actions function when utilizing {{kib}} spaces. |
There was a problem hiding this comment.
| This page introduces {{elastic-sec}} space awareness and answers frequently asked questions about how {{elastic-defend}} integration policies, {{elastic-endpoint}} artifacts, and {{elastic-endpoint}} response actions function when utilizing {{kib}} spaces. | |
| This page introduces {{elastic-sec}} space awareness and answers frequently asked questions about how {{elastic-defend}} integration policies, endpoint artifacts, and endpoint response actions function when using {{kib}} spaces. |
|
|
||
| ::::{admonition} Key points | ||
| * Artifacts such as trusted applications, event filters, and response action history are scoped by space to provide granular control over access. | ||
| * Role-Based Access Control (RBAC) defines who can manage global and space-specific resources. Users can view, edit, or manage artifacts based on their role privileges and the space context. |
There was a problem hiding this comment.
| * Role-Based Access Control (RBAC) defines who can manage global and space-specific resources. Users can view, edit, or manage artifacts based on their role privileges and the space context. | |
| * Role-based access control (RBAC) defines who can manage global and space-specific resources. Users can view, edit, or manage artifacts based on their role privileges and the space context. |
| ::::{admonition} Key points | ||
| * Artifacts such as trusted applications, event filters, and response action history are scoped by space to provide granular control over access. | ||
| * Role-Based Access Control (RBAC) defines who can manage global and space-specific resources. Users can view, edit, or manage artifacts based on their role privileges and the space context. | ||
| * You need the global management privilege to manage global artifacts (those not associated with specific policies). |
There was a problem hiding this comment.
Does this refer to Global Artifact Management?
If so, we should also doc this privilege on the feature privileges page.
| :::: | ||
|
|
||
| ::::{note} | ||
| {{elastic-sec}}'s space awareness works in conjunction with {{fleet}}'s space awareness. space awareness is enabled by default in both applications, but for {{stack}} deployments that existed prior to version 9.1, {{fleet}} requires you to manually “opt-in” so that existing data can become space aware. To learn more, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md). |
There was a problem hiding this comment.
| {{elastic-sec}}'s space awareness works in conjunction with {{fleet}}'s space awareness. space awareness is enabled by default in both applications, but for {{stack}} deployments that existed prior to version 9.1, {{fleet}} requires you to manually “opt-in” so that existing data can become space aware. To learn more, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md). | |
| {{elastic-sec}}'s space awareness works in conjunction with {{fleet}}'s space awareness. Space awareness is enabled by default in both applications, but for {{stack}} deployments that existed prior to version 9.1, {{fleet}} requires you to manually “opt-in” so that existing data can become space aware. To learn more, refer to [](/reference/fleet/fleet-roles-privileges.md). |
There was a problem hiding this comment.
Same comment here: Linking to fleet privileges pages does not seem to make sense here. We should link instead to the Fleet page that describes how they support Spaces instead (if that exists)
| ## General FAQ [spaces-security-faq-general] | ||
| **What are spaces in {{kib}}, and how do they affect what I see?** | ||
|
|
||
| spaces allow your organization to segment data and configurations within {{kib}}. If you're working in a specific space, you’ll only see the policies, {{agents}}, {{elastic-endpoint}}s, and data that belong to that space. |
There was a problem hiding this comment.
| spaces allow your organization to segment data and configurations within {{kib}}. If you're working in a specific space, you’ll only see the policies, {{agents}}, {{elastic-endpoint}}s, and data that belong to that space. | |
| Spaces allow your organization to segment data and configurations within {{kib}}. If you're working in a specific space, you’ll only see the policies, {{agents}}, endpoints, and data that belong to that space. |
| in order to use this API, you need {{kib}}'s built-in `superuser` role. | ||
| :::: | ||
|
|
||
| :::{dropdown} View current orphan response actions space id: |
There was a problem hiding this comment.
| :::{dropdown} View current orphan response actions space id: | |
| :::{dropdown} View current orphan response action's space ID: |
| :::{dropdown} View current orphan response actions space id: | ||
|
|
||
| API call: | ||
| `GET /internal/api/endpoint/action/_orphan_actions_space` |
There was a problem hiding this comment.
Our publicly available API endpoints typically don't have /internal/ in their path – @paul-tavares, just checking this is right?
| No, response actions will not work unless a connector for the given third party EDR exists in the space where the policy was moved. Connectors are space specific and can not be shared or moved to a new space, thus a new instance of the connector must be created in the new space so that the policy in that space can send response actions to the third party system. | ||
|
|
||
|
|
||
| ## What are orphan response actions? [spaces-security-faq-orphan-response-actions] |
There was a problem hiding this comment.
| ## What are orphan response actions? [spaces-security-faq-orphan-response-actions] | |
| ### What are orphan response actions? [spaces-security-faq-orphan-response-actions] |
| To remove the space ID where orphan response actions appear, call the API with an empty string for `spaceId`. | ||
|
|
||
|
|
||
| ## Endpoint Detection Rules [spaces-security-faq-endpoint-detection-rules] |
There was a problem hiding this comment.
| ## Endpoint Detection Rules [spaces-security-faq-endpoint-detection-rules] | |
| ## Endpoint protection rules [spaces-security-faq-endpoint-protection-rules] |
| ## Endpoint Detection Rules [spaces-security-faq-endpoint-detection-rules] | ||
|
|
||
| By default, prebuilt detection rules use an index pattern that may be too broad for use in a particular space. In order to ensure that the space only shows the desired data in that space, you may need to customize the rule. | ||
| For example, the {{elastic-defend}} rule has an index pattern that picks up all data sent to `logs-endpoint.alerts-*`. This index pattern would pick up all events sent by Elastic Defend which may not be desirable. |
There was a problem hiding this comment.
| For example, the {{elastic-defend}} rule has an index pattern that picks up all data sent to `logs-endpoint.alerts-*`. This index pattern would pick up all events sent by Elastic Defend which may not be desirable. | |
| For example, the Endpoint Security ({{elastic-defend}}) rule has an index pattern that picks up all data sent to `logs-endpoint.alerts-*`. This index pattern would pick up all events sent by {{elastic-defend}}, which may not be desirable. |
There was a problem hiding this comment.
Some initial feedback. I see that @natasha-moore-elastic has provided several comments to the FAQ page - some of which I was also going to provide - so I did not review that page. I will wait for the revised version to be available and will then do a full review on it.
| @@ -19,10 +19,9 @@ You can create user roles and define privileges to manage feature access in {{el | |||
| To configure roles and privileges, find **Roles** in the navigation menu or by using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). For more details on using this UI, refer to [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-role-management.md) for {{stack}}, or to [Custom roles](/deploy-manage/users-roles/cloud-organization/user-roles.md) for {{serverless-short}}. | |||
|
|
|||
| ::::{note} | |||
| {{elastic-defend}}'s feature privileges must be assigned to **All Spaces**. You can’t assign them to an individual space. | |||
| {applies_to}`stack: ga 9.1` {{elastic-defend}}'s feature privileges can be assigned on a per-space basis. For information about how to apply permissions to particular spaces, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md). | |||
There was a problem hiding this comment.
I got confused why we link to fleet page here for setting up per-space roles. I think we should link to our own docs on how to setup roles per space (if that exists... Or maybe that is what this page is for 🤔 ). When it comes to RBAC, we really have no dependency on Fleet. Our privileges for endpoint management will enable our functionality even if a user does not have access to fleet.
Also - and perhaps more important: the table below that lists all of the Endpoint Management related privileges is missing the new Global Artifact Management privilege which will be introduced with the availability of this spaces feature.
The new privilege is displayed in Kibana this way:
Global Artifact Management
Manage global assignment of endpoint artifacts (e.g., Trusted Applications, Event Filters) across all policies. This privilege controls global assignment rights only; privileges for each artifact type are required for full artifact management.
| {{elastic-sec}} supports the organization of your security operations into logical instances with the [spaces](../../../deploy-manage/manage-spaces.md) feature. Each space in {{kib}} represents a separate logical instance of {{elastic-sec}} in which detection rules, rule exceptions, value lists, alerts, Timelines, cases, and {{kib}} advanced settings are private to the space and accessible only by users that have role privileges to access the space. | ||
|
|
||
| ::::{note} | ||
| {applies_to}`stack: ga 9.1` You can control user access to features in and managed by {{fleet}} (including {{elastic-defend}}) on a per-space basis. This granularity helps you fine-tune which components each user can access and which actions they can perform. To learn more, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md), and [{{elastic-sec}} requirements](elastic-security-requirements.md). |
There was a problem hiding this comment.
Same comment here. Linking to the Fleet Roles and Privileges page does not make sense to me. You probably need to contact the fleet team and find out what page in their docs contains information specific around the Spaces feature implementation which hopefully includes the some instructions for existing customers to follow when wanting to take advantage of this feature.
I do think this page is missing some information around how spaces are managed/used from an Elastic Defend standpoint, which is different from how Elastic Security (ex. SIEM, Timelines, etc) are managed, so perhaps a sub-section here for Elastic Defend may be appropriate. Here is some info. I that I would suggest (@caitlinbetz please adjust if necessary)
Elastic Defend
Elastic Defend management support of spaces works in conjunction with Fleet support for spaces. The visibility of hosts running Elastic Defend in a given space is managed from Fleet by assigning Agent Policies to the given space (you could link to fleet specific documentation on this topic if that exists). Management and configuration of Elastic Defend policies and hosts functions as normal with a few caveats - see the FAQ for more information (<< Link to the new FAQ page).
| - id: cloud-serverless | ||
| --- | ||
|
|
||
| # Spaces and {{elastic-sec}} FAQ [security-spaces-faq] |
There was a problem hiding this comment.
I think the title of this page (and throughout the content below) should be specific for Elastic Defend, since these are only applicable to that component from within Elastic Security. They do not apply to how spaces work for other Security areas (ex. SIEM, Timeline, etc)
| :::: | ||
|
|
||
| ::::{note} | ||
| {{elastic-sec}}'s space awareness works in conjunction with {{fleet}}'s space awareness. space awareness is enabled by default in both applications, but for {{stack}} deployments that existed prior to version 9.1, {{fleet}} requires you to manually “opt-in” so that existing data can become space aware. To learn more, refer to [Fleet roles and privileges](/reference/fleet/fleet-roles-privileges.md). |
There was a problem hiding this comment.
Same comment here: Linking to fleet privileges pages does not seem to make sense here. We should link instead to the Fleet page that describes how they support Spaces instead (if that exists)
|
|
||
| ## Endpoint Detection Rules [spaces-security-faq-endpoint-detection-rules] | ||
|
|
||
| By default, prebuilt detection rules use an index pattern that may be too broad for use in a particular space. In order to ensure that the space only shows the desired data in that space, you may need to customize the rule. |
There was a problem hiding this comment.
| By default, prebuilt detection rules use an index pattern that may be too broad for use in a particular space. In order to ensure that the space only shows the desired data in that space, you may need to customize the rule. | |
| By default, [endpoint protection rules](/solutions/security/manage-elastic-defend/endpoint-protection-rules.md) use an index pattern that may be too broad for use in a particular space. In order to ensure that the space only shows the desired data in that space, you may need to customize the rule. |
I thought I added this suggestion in my initial review, but looks like I missed it.
Fixes #1514
Updates the Spaces for Elastic Security and Elastic Defend feature privileges pages (<- previews). Adds information about the space-awareness capabilities for Defend and other Security-specific Fleet features.
The biggest change is the creation of the Spaces and Elastic Security FAQ (preview)